Your linter is not happy, but it doesn't say anything about what is wrong...

Your linter is not happy, but it doesn't say anything about what is wrong...

Appears that it needs black formatting. You can run lint locally to check it out.

Wow, I didn't realize this could be so simple! Re: FW upgrades, if "image upload" is used, then the FW would not be expected to swap. To run a routine that swaps the FW, try "upgrade".

lint locally wasn't any more helpful. Is there a verbose of fix option?

My test was with "upgrade".

lint locally wasn't any more helpful. Is there a verbose of fix option?

My test was with "upgrade".

You'll need to run black on the files that need to be formatted.

May be helpful to enable debug logging, though some error should be indicated if the swap request is rejected.

You can run image state-read to see if your upgrade is correctly in the secondary.

I tried image state-read. Is this probably the old firmware?

ImageState(
    slot=0,
    version='0.0.0',
    image=None,
    hash=HashBytes(
        '<hash>'
    ),
    bootable=True,
    pending=False,
    confirmed=True,
    active=True,
    permanent=False
)
splitStatus: 0

I should add --diff --color to the envr alias: https://black.readthedocs.io/en/stable/usage_and_configuration/the_basics.html#diff

I tried image state-read. Is this probably the old firmware?

ImageState(

    slot=0,

    version='0.0.0',

    image=None,

    hash=HashBytes(

        '<hash>'

    ),

    bootable=True,

    pending=False,

    confirmed=True,

    active=True,

    permanent=False

)

splitStatus: 0

Likely! You can try image upload --slot 2, then read again and see what you see.

Slot 2 not 1?

Yes, black --diff is great and worth mentioning.

I took the chance on slot 2 :)

ImageState(
    slot=0,
    version='0.0.0',
    image=None,
    hash=HashBytes(
        '<same hash>'
    ),
    bootable=True,
    pending=False,
    confirmed=True,
    active=True,
    permanent=False
)
ImageState(
    slot=1,
    version='0.0.0',
    image=None,
    hash=HashBytes(
        '<another hash>'
    ),
    bootable=True,
    pending=False,
    confirmed=False,
    active=False,
    permanent=False
)
splitStatus: 0

There are lots of (every packet) these warnings when uploading:

           WARNING  Overriding self.version=<Version.V2: 1> with message.py:115
                    self.header.version=<Version.V1: 0> from the               
                    provided header. - message:115                             

Are you happy with the command syntax? smpmgr --ble <address> ?
Or did you have something else in mind, like smpmgr --ble --port <address> ?

The upgrade gave no other warnings.

⠋ Waiting for response to ResetWrite... OK
Upgrade complete.

I used upgrade --slot 2 and it worked! I am a happy camper! Seems like this is the only SMP over BLE command tool on Linux. I tried also AuTerm but it is a GUI with no possibilities of scripting.

Slot 2 not 1?

Yes, this is a whole mess! You can read about it here, it needs to be improved: #3

There are lots of (every packet) these warnings when uploading:

           WARNING  Overriding self.version=<Version.V2: 1> with message.py:115
                    self.header.version=<Version.V1: 0> from the               
                    provided header. - message:115                             

There are 2 parts to this:

• You are either using an old SMP server or a new SMP server configured for legacy compatibility. In Zephyr, you should set CONFIG_MCUMGR_SMP_LEGACY_RC_BEHAVIOUR=n: https://docs.zephyrproject.org/latest/kconfig.html#CONFIG_MCUMGR_SMP_LEGACY_RC_BEHAVIOUR
• But, this is still an issue. smpmgr/smpclient are sending V2 packetss and the server is sending back V1 packets when V2 is expected. This will be fixed here: Convenience methods should expose SMP version kwarg smpclient#43

Are you happy with the command syntax? smpmgr --ble <address> ?
Or did you have something else in mind, like smpmgr --ble --port <address> ?

For now, smpmgr --ble [address] is great... though we need to make address optional - it will find the device as long as the SMP service is advertised. This will be feature version 0.9.0.

This will all be different in smpmgr 1.0.0. It's become clear that each transport should be its own subcommand group so that it can handle all the different arguments. The transport groups will be usb uart ble can udp. Usage like smp uart [a bunch of transport specific options] upgrade [args].

I used upgrade --slot 2 and it worked! I am a happy camper! Seems like this is the only SMP over BLE command tool on Linux. I tried also AuTerm but it is a GUI with no possibilities of scripting.

Great! For scripting, I might recommend using smpclient directly - there are lots of examples scripts in that repo as HW integration tests. You can see example implementation in ESPHome here, for example: https://github.com/esphome/esphome/pull/6075/files#diff-493f483da80bddf50eae6653dda1843815a142b1b1912e4df0541aa3b7097439

For Linux shell scripting, maybe smpmgr is better. I'd recommend pipx over the portable though.

Thanks for the contribution, I will test and merge ASAP.

FYI: I've tested running parallel upgrades, even on multiple different transports, and this will definitely be a feature. E.g. it can be configured to scan for all BLE devices and upgrade them all in parallel, or upgrade all attached USB devices - good potential for factory tooling! No impact to speed of upgrade.

BTW, what is your upload speed? We're expecting 10kB/s -> 25kB/s over BLE. I usually see about 15kB/s in Windows.

Just noted that when I use --slot so it works, this is printed at the end:
The device may take a few minutes to complete FW swap.

The speed I get is 40.9 kB/s according to the progress bar when it is done.

The speed I get is 40.9 kB/s according to the progress bar when it is done.

That's wild. One thing that can cause it to report really fast uploads is if the image you're uploading is already on the device. When that happens, it sees that the SHA matches and doesn't do the upload.

What chip are you testing?

It is an nRF5340 and my laptop has a Intel Corp. AX201 Bluetooth module. I can test again with a clock and new image.

For Linux shell scripting, maybe smpmgr is better. I'd recommend pipx over the portable though.

Would be nice to have a release in pipx with BLE support soon :)

For Linux shell scripting, maybe smpmgr is better. I'd recommend pipx over the portable though.

Would be nice to have a release in pipx with BLE support soon :)

Probably within a few days! I want to test it with HW.

The firmware is 326700 bytes and the whole command (measured with "time") is e.g. 10.3 s so with the connection overhead removed I guess the transport is somewhere around 9 seconds. That would give 36 KB/s, or 32 KB/s included the whole invocation and connection overhead. But the reported speed from smpmgr is above 40 KB/s, also seen 44.4 KB/s once.

The firmware is 326700 bytes and the whole command (measured with "time") is e.g. 10.3 s so with the connection overhead removed I guess the transport is somewhere around 9 seconds. That would give 36 KB/s, or 32 KB/s included the whole invocation and connection overhead. But the reported speed from smpmgr is above 40 KB/s, also seen 44.4 KB/s once.

OK, that seems to confirm the speeds. Hard for there to be a math error in the KB/s calculation.

I gotta get a 53 dev kit. That BLE transfer is almost as fast as USB speeds on other boards, which makes me wonder how fast the USB transport upload is on that chip.

The 52840 is the one where I tend to see 10-25 KB/s via BLE.

OK, it's working for me on Windows + nrf 52840. I am connecting by using device name, e.g. smpmgr --ble MyDeviceName os echo hello.

I am going to push some other changes to main since I ended up needing longer timeouts (Windows BLE is ... not fun).

Will tag you on release.

@tormodvolden OK, should be on pipx now, LMK if there are any problems: https://pypi.org/project/smpmgr/

@tormodvolden OK, should be on pipx now, LMK if there are any problems: https://pypi.org/project/smpmgr/

Wow! Thanks so much!